Business Analyst Community & Resources | Modern Analyst

What Is Socio-Technical Architecture?

Adrian M. — Sun, 19 Oct 2025 22:38:00 GMT

In short, socio-technical architecture is the holistic design of how technology and people co-create value within an enterprise system. It ensures that the “architecture of the system” and the “architecture of the organization” evolve together.

For business analysts, this mindset elevates requirements work from specification to system stewardship—making sure that both the software and the people using it perform in harmony to achieve business outcomes.

What are Wireframes?

Adrian M. — Mon, 10 Mar 2025 00:49:00 GMT

Wireframes are visual representations of a webpage, application, or system interface, outlining the structure, layout, and functionality of a digital product. They serve as blueprints that help stakeholders, designers, and developers understand the placement of key elements before actual development begins.

Purpose of Wireframes

Wireframes help in early-stage planning by focusing on:

User Experience (UX) Design – Ensuring logical and intuitive navigation.
Information Architecture – Organizing content in a user-friendly way.
Functional Layout – Defining interactions like buttons, menus, and forms.
Stakeholder Communication – Aligning expectations among business teams, designers, and developers.

Types of Wireframes

Low-Fidelity Wireframes – Simple sketches, often hand-drawn or created using basic tools like Balsamiq. These focus on layout and structure without design details.
Mid-Fidelity Wireframes – More refined versions with structured placeholders for images, text, and buttons. Created in tools like Figma or Axure.
High-Fidelity Wireframes – Detailed representations that closely resemble the final UI, often including typography, colors, and interactions. Used for development-ready designs.

Example Use Case for Business Analysts

Imagine a business analyst is working on a new online banking portal. Before developers start coding, the analyst collaborates with UX designers to create wireframes that outline:

Login Screen – Placement of username, password, and authentication options.
Dashboard Layout – Sections for account summary, transactions, and quick actions.
Navigation Flow – How users move between account details, fund transfers, and settings.

These wireframes ensure all stakeholders agree on the structure before investing time in UI/UX design or development.

Why Wireframes Are Important for Business Analysts

For business analysts, wireframes serve as a visual tool to:

Clearly define system requirements and functionality.
Improve stakeholder collaboration by offering a tangible representation of ideas.
Identify potential UX issues early, reducing costly rework in development.
Enhance documentation by linking wireframes to business process flows and user stories.

In summary, wireframes are essential for business analysts to bridge the gap between business needs, user expectations, and technical feasibility, ensuring efficient and user-friendly system design.

What are some pros and cons of requirements reuse?

Chris Adams — Mon, 13 Dec 2021 17:28:00 GMT

Requirements reuse is when the same written requirement is used repeatedly within a single project, across a product line, or even across an enterprise. Requirement reuse can be as simple as an analyst copy/pasting requirements from a previous project, or it can be as sophisticated as having a central repository of requirements that documents link to.

What is Structured English (aka pseudocode)? Please provide an example.

Adrian M. — Mon, 09 Aug 2021 13:00:00 GMT

Structured English or pseudocode is a technique used by systems analysts (and sometimes by IT business analysts) to model and document logic of information processes.

Describe some pros and cons of using templates that aid in creation of BA deliverables.

Chris Adams — Fri, 12 Mar 2021 17:53:00 GMT

Templates can be useful, but with many tools available to the business analyst they come with their pros and cons.

List the steps you would take to bring a product from idea to deployment and beyond.

Chris Adams — Sun, 08 Nov 2020 20:14:00 GMT

Some of these steps could be combined, pared down, or avoided altogether depending on the demands of the project and complexity of the product or application. Use the minimum amount of tools, models, and specifications needed to communicate the necessary information to the coders in a way that ensures the final product meets the expectations of the customer and is defect free. Once might refer to this as “just enough documentation” – not too much, but not too little.

Why are modeling techniques so important to Business Analysts, and how do you choose the right ones for your project?

Chris Adams — Mon, 08 Jun 2020 17:30:00 GMT

Grouping related items (whether requirements, ideas, business processes, etc.) into a diagram or model is just a way of forming them into recognizable and (hopefully!) familiar patterns. And the short-term memory limit is much less constraining if people are asked to remember and absorb a few different patterns as opposed to dozens of individual bits of information.

What strategies can the BA and project team use to facilitate stakeholder sign-off on requirements?

Chris Adams — Mon, 14 Jan 2019 15:05:00 GMT

There are several steps that the BA and project team can take beyond just publishing requirements with a sign-off deadline, in order to ease the process for stakeholders and expedite approvals:

Make sure the right people are signing-off on requirements. It sounds simple and obvious, but this can be one of the biggest contributors to challenges in obtaining requirements sign-off, particularly on complex multi-stakeholder projects.
Help stakeholders understand the sign-off process. Provide a clear explanation of the commitment that stakeholders are making to the project by signing off on requirements. Be sure to communicate the process for identifying and managing subsequent changes after sign-off (which may be just a reminder of the project’s established change control procedures).
Help stakeholders interpret the requirements documentation. Where feasible and applicable, provide supporting or reference material to assist interpretation and understanding of the requirements. This may include glossaries and data dictionaries, diagrams, etc. It is also very helpful to maintain a log of all decisions that are made throughout requirements definition, and publish this decision log with the requirements to avoid revisiting past decisions.
Make sure stakeholders have enough time to review the requirements during sign-off. Plan ahead for review and sign-off cycles as much as possible. Remind stakeholders of this commitment 2-3 weeks prior to each review cycle, so they have enough advance notice to plan for the time needed.
Foster collaborative ownership on multi-stakeholder projects. If a single document contains requirements that are shared or jointly owned, individual stakeholders may be reluctant to sign-off on requirements that they do not individually own. Joint review sessions can be used for collaborative discussion with the goal of obtaining verbal approval from the group during the session. Stakeholder questions or concerns can be addressed through the group review, which will help expedite sign-off from each individual participant.

--
Sandy Lambert
Business Architect
LinkedIn Profile

In which document do you include the Class Diagram (business requirements, functional requirements, software specification document)?

sonavi — Mon, 12 Nov 2018 16:20:00 GMT

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

How are non-functional requirements defined and managed on Agile projects?

Chris Adams — Mon, 12 Mar 2018 14:55:00 GMT

Non-functional requirements (NFRs) are typically defined as backlog constraints on an Agile project, and are managed as part of both product backlog and scrum backlog. They are revisited as part of the ‘Definition of Done’ for each iteration or sprint. If the system does not meet any given NFR, that NFR may spawn new backlog items such as refactors or performance enhancements.

What is Gherkin and how can it help the business analyst?

Chris Adams — Mon, 09 Oct 2017 17:52:00 GMT

Gherkin is a structured natural language that is used by business analysts to specify how they want the system to behave for given scenarios. The Gherkin language is simple. It uses about 10 keywords (Given, When, Then, And, But, Scenario, Feature, Background, Scenario Outline, Examples) which allow the language to be read and parsed by an automation tool called Cucumber.

Once a system is developed is it reasonable to document changes with simple updates to screen mockups?

Chris Adams — Sun, 10 Sep 2017 22:16:00 GMT

This question implies that the benefit of foregoing the creation of a more complete requirements specification document is a significant amount of time savings. But what might we be losing in the process.

Screen mockups alone don’t clearly document requirements. Instead, they reflect a decision made by the system designer to satisfy a particular requirement. Often when someone views the mockup or updated system they may think the requirement is obvious when, actually, they have misinterpreted the true requirement.

In User Centered Design, should analysts create a separate Personas for every demographic segment?

Chris Adams — Sun, 13 Aug 2017 18:45:00 GMT

Personas are used in User Centered Design to represent the audience that you are designing for. Each persona is a detailed profile of a fictional character which represents a different user segment. They are created in such a way as to bring a strong sense of realism to the users they represent. This helps create a visceral connection with the personas so that the system designer can really understand the users’ motivations for using the product. Personas primarily focus on a user’s attitudes and behaviors.

How do you avoid requirement conflicts while making changes to an existing system where no documentation exists?

Chris Adams — Sun, 13 Dec 2015 20:41:00 GMT

Companies with small IT departments or analysis teams often lack a well defined analysis process. It's not uncommon for analysts to be hired onto a team and find that they are being asked to assist with requirements and new features for a system where no documentation exists. In this case, the analyst needs to create a minimal amount of documentation retroactively.

What is a Use Case Realization?

Chris Adams — Sat, 08 Aug 2015 16:31:00 GMT

A use case realization provides a construct to organize artifacts which shown how the physical design of a system supports the logical business behavior outlined by a used case. Each use case realization will define the physical design in terms of classes and collaborating objects which support the use case. Therefore, each use case realization typically is made up of a class diagram and a number of interaction diagrams, most commonly sequence diagrams, showing the collaboration or interaction between physical objects.

What is the difference between a use case alternative flow and an exception flow?

cadams — Sun, 12 Oct 2014 06:13:00 GMT

A use case specification describes the functionality of a system in terms of a sequence of user-system interactions. The main flow of events describes a single path through the system. It represents the most common way that the use case plays out successfully and contains the most common sequence of user-system interactions. Other scenarios or paths through the system are described in alternative flows and exception flows. So what is the difference between and alternative flow and an exception flow?

When implementing a purchased solution should your requirements and design documents cover features that were not requested but come with the package?

Chris Adams — Sun, 07 Sep 2014 18:22:00 GMT

When implementing a purchased solution at a minimum each additional feature needs to be assessed to determine its potential positive or negative impact.

What is an epic, and what purpose does it serve on an Agile project?

Chris Adams — Fri, 09 May 2014 14:58:00 GMT

Business epics are large, typically cross-cutting initiatives that encapsulate new development needed to realize certain business benefits. One or more epics can form the basis for the business case that justifies and initiates a project.
Epics are often used as placeholders for new ideas that have not been thought out fully, or whose full elaboration has been deferred until actually needed. Epics are then evolved into split into multiple user stories that help Agile development teams effectively manage and groom their product backlog.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is a wireframe, and how is it different from a screen mock-up?

Chris Adams — Thu, 09 Jan 2014 18:24:00 GMT

A wireframe is a static blueprint or schematic of a user interface, used as a visual aid in identifying basic functionality and navigation requirements. A wireframe is different from a screen mock-up because it does not include any elements of screen design, style or graphics. A wireframe focuses on what the user interface or screen does, rather than how it looks.
--
Sandy Lambert
Business Architect
LinkedIn Profile

Can requirements for a system interface be documented as a use case?

Chris Adams — Wed, 04 Dec 2013 22:08:00 GMT

Yes, a use case can be used to document requirements for system-to-system interactions and exchanges of information between systems. External systems are treated as Actors, in the same way as human Actors. The standard use case structure of pre-conditions, post-conditions, basic flow, alternate flows and exception flows are all applicable when describing the requirements for interactions with an external system Actor as with a human Actor.

A key rule for this type of use case is that external systems must always be treated as ‘black-box’ entities. The use case cannot dictate requirements for external system processing beyond the bounds of its interaction with the in-scope software system. For example, requirements for an online retail sales system (“System X”) may include an interface to an external third-party payment system such as Paypal (“System Y”). The use case for this interface would describe what information shall be sent from System X to the external system Actor, what information shall be received by System X from the external system Actor, and what System X shall do in order to process the information exchanged. The use case cannot contain requirements for any processing that occurs within the external system (cannot describe data that System Y must collect, connect describe edits that System Y should perform, etc.).

Pre-conditions also must not describe anything that happens within the external system. A pre-condition can only be something that is known to or detected by the in-scope system.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is OOAD?

Chris Adams — Sun, 09 Sep 2012 16:25:00 GMT

The acronym OOAD stands for Object Oriented Analysis and Design. OOAD is a software engineering approach that models and designs a system as a group of interacting objects. Object is the term used to describe some entity or “thing” of interest. These objects are typically modeled after real world entities or concepts. For the business analyst, these would be the real-world entities that arise within the business (invoice, product, contract, etc).

Objects have attributes which can be set to specific values. This defines the state of the object. Objects also have methods or functions which define their behavior.

Here is a quick example for illustrative purposes. Consider the real world object “Car”. Our car has attributes that can be defined with specific values such as,

make = ford
model = escape
year = 2002
color = green
maximum speed = 130 mph
current speed = 50 mph
ideal tire pressure = 35 psi
current tire pressure = 31 psi
remaining fuel = 12 gallons

Each of these attributes define the “state” of the vehicle. They describe the car as it is at some point in time. Additionally, the car has certain “behaviors” such as

accelerate ()
decelerate ()
refuel ()
fill tires ()

Each of these behaviors of the real world object can be represented as a method of the object when designing the system (methods are also known as a functions in some programming languages). These methods can change the values of the attributes causing a change in state.

OOAD is comprised of two parts:

(1) object oriented analysis

(2) object oriented design

Models of different types can be created to reflect the static structure, dynamic behavior, and run-time deployment of the collaborating objects of a system.

During the object-oriented analysis (OOA) phase object-modeling techniques are used to analyze the functional requirements for a system and create models which reflect the logical design of the system. During the object-oriented design (OOD) phase of the system, models are elaborated upon to include implementation specific details that show how the physical design of the system will come together. OOA focuses on what the system does (its static structure and behavior), OOD on how the system does it (it’s run-time implementation).

What is a Swimlane Diagram?

Chris Adams — Sat, 09 Apr 2011 22:42:00 GMT

A swimlane diagram (also sometime called a cross-functional diagram) documents the steps or activities of a process flow or workflow. More specifically, a swimlane diagram groups these activities into swimlanes which are horizontal or vertical columns that contain all of the activities which fit into the category represented by that swimlane. Swimlanes can represent many categories of information such as actors which perform the activities (i.e., role or department), the stage of the process in which the activity takes place, or whatever else the creator of the document feels should be emphasized and communicated by the swimlane diagram. The term swimlane was adopted due to the visual similarity between the horizontal rows of the diagram to that of the swimlanes found within a swiming pool.

A process flow or workflow diagram does not have to use swimlanes. However, since swimlanes communicate additional information about who performs the activity or when it takes place, it’s typically a preferred best practice to include them. Similarly, a swimlane diagram can use only one set of swimlanes (either vertical swimlanes or horizontal swimlanes). In BPMN standards, a process flow is typically shown flowing from left to right. If only one set of swimlanes is used, horizontal swimlanes are most commonly used to group activities. In the UML standard, the activity diagram flows from top to bottom and veritcal swimlanes are most commonly used.

One of the more common choices used by creators of swimlane diagrams is to define the roles which perform each activity within horizontal swimlanes and define the process stages in which the activity occurs within vertical swimlanes.

Why is requirements traceability important?

Chris Adams — Fri, 08 Aug 2008 15:36:00 GMT

Requirements traceability is the ability to follow and audit the life of a requirement, in both a forward and backward direction; from its origins, through its realization in the design and functional specifications, to its eventual development and deployment and use, through subsequent rounds of modification and refinement.

If a requirement is changed or modified, using a requirements traceability matrix the analyst can identify those areas within the functional specifications that are impacted by the requirement and make the appropriate modifications. In addition, the analyst can determine if the portion of the specification being modified traces back to any other requirements. This is important to ensure that the new modification doesn’t break any existing requirements within the system.

Similarly, sections of the specification can be traced to areas of the physical code to ensure that all required changes are made during the development process. Test cases can also be traced back to functional specifications. When functional specifications are changed test cases nearly always need to be updated to ensure complete and accurate testing can take place.

--
Chris Adams
LinkedIn Profile

What is the difference between a Business Requirement Document (BRD) and a Functional Specification Document (FSD)?

BAZ — Thu, 03 Jul 2008 16:10:00 GMT

Business Requirement Documents are written to define the requirements of a business process or a system that needs to support a business process. For purposes of contrasting the Business Requirement Document (BRD) and the Functional Specification Document (FSD), the description of the BRD that follows is written in terms of preparing a BRD for a system. The exact scope of a BRD and FSD vary from company to company. However, the two documents are typically defined as follows:

The BRD contains the business requirements that are to be met and fulfilled by the system under development. These requirements specify "what" the system must do in order to fulfill the requirements of the business. They often take the form of "The system shall..." Each requirement, or group of similar requirements, is typically accompanied by a business rationale. The business rationale explains "why" the business requirement is necessary. This is often important later if analysts or developers have questions regarding the purpose or validity of the requirement. The rationale can be used to support the need for the business requirement or clarify ambiguous language by providing a context for the requirement. In addition to a rationale, constraints can be provided for each requirement along with other supporting reference material.

In contrast, the FSD defines "how" the system will accomplish the requirements by outlining the functionality and features that will be supported by the system. Ideally, the functionality of the system will be described in logical terms so that the FSD is technology and platform independent. This gives the architects and developers more freedom in making development and design decisions about the physical design of the system. Inevitably, however, some things have to be explained in physical terms. The User Interface is one such example. Many FSDs include screen mockups or wireframes for communicating the layout and design of the system screens.

Are there scenarios where the developers will produce something different from your requirements spec, and how would you handle this?

Emy — Sun, 13 Jan 2008 15:46:00 GMT

Yes, there are instances when the developers will produce something different than what the requirements or functional specification documents contain. Here are some of the instances/causes of such differences:

The specifications are ambiguous or incomplete and they can be easily interpreted in multiple ways. In this case, the developer may have simply misinterpreted the ambiguous requirement in a different way than what was intended.
The developer simply ignored the specification and/or just read it quickly and then developed the system from memory.
The development team encountered technical limitations and the system cannot be developed exactly the way they were specified.

In general, the best way to handle this is to have a clear process in place to manage differences between the specification and the developed product. This would require a strong QA team and QA process. Here are some more detailed which address the three items above:

First and foremost, ensure that the business analysis team has documented guidelines for creating requirements and functional specifications as well as processes in place for peer and management review of analysis artifacts to ensure they are accurate and unambiguous. In addition, since the QA team is responsible for creating test cases and scenarios based on the requirements and functional specifications, they should look for, find, and document as spec defects (bugs) those areas of the analysis artifacts which are ambiguous or are missing information. These defect reports can be used by the analysis manager to identify areas of improvement and also to provide performance feedback to the individual business systems analyst.
Create a process in the development team for each developer to be accountable for his/her deliverables and produce code which is defect free. In addition, the QA team should be able to find these discrepancies and create defect reports (bugs) for the development team to fix.
A process should be in place to deal with instances when the requirements cannot be implemented as outlined in the functional specifications. Have the development team review the functional specs and provide feedback before the coding starts. The development team should be a key stakeholder and reviewer of the analysis artifacts. The feedback can then be incorporated back into the analysis artifacts and, hopefully, resulting in the alignment of the specifications and developed product.